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(54) System for context-dependent name resolution 



(57) A context-depen dent, multiply binding name 
resolution system. A name resolver is.:provided, con- 
nected to either a requester' s system oca receiver's_s ys- 
te m. or both. Requests to a given se rvice or domain 
name are resolved to th e ^a^^ p ^e)iP^ddress. The 
intended recipient ot theTequest is resolved based upon) 
a combination oj_qne or morepredetermined criteria, in- 
cluding: information about.the sender (e.g. geographical 



location, specific requester identity, etc.); information 
about the intended recipieht (e.g. lo ad balance at .t he 
receiver^ ty pe of service, e tc.); information contained 
within the requjssUtsetf (e.g. type of service requested); 
or other informa tion (time of day, date, random selection 
of recipient, e.g.). The system is implemented in hard- 
ware and/or software, and the r esolution criteria can b e 
made interdependent or independent. _ . 
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Figure 3 
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Description 

This invention relates to systems for context <Je- 
pendent name resolution. 

In a network (either Intranet or Internet) system, 
when a host wants to communicate with another host or 
locate a service or another host on the network, the ad- 
dress is typically resolved in an absolute manner; that 
is, the naming service of the network resolves a given 
name to a single IP (Internet Protocol) address. For in- 
stance, a^dcjaain_oanae_servjce.(DNS) call resolves a 
na me to a s inglej P_a ddress or hos t name on the Inter- 
net. 

When there are many connections to a given host 
or service, the resulting congestion degrades the overall 
performance. The service provider may upgrade the 
service, e.g. to increase its capacity. In this case, in or- 
der to keep the modification of the service transparent 
to requesting hosts, a demultiplexer may be used, as 
illustrated by way of example in Figures 1-2. For in- 
stance, in Figure 1 a call to S ervic e 3w ill be uniquely 
resolved to that service's IP address and transm itted 
th ere accordingly, because there is only a single binding 
in th e DNS name re sol ver to the host of Service 3. In 
general, in a conventional system such as that illustrat- 
ed in Figures 1 , 2 and 2A, there will be a singl e binding 
between a name an d an IP address. 

Yet another alternativelsTofa special type of de- 
multiplexer, which may monitor the traffic, and from the 
different IP addresses can collect statistics such as re- 
sponse time and/or the load_ pn the corresponding IP 
hosts, ancLu VeJhis informaj tiojiJo Tjoad balancing by 
bindj no a .requested name to an IP addr e ( ssJnL.aJiQst 
-whirh, is Ififtsjiftpyjly Insert 

If Service 3 is upgraded to include Services 3.1 
through 3^Y P then the demultiplexer is added (see Figure 
2); the requesting or DNS resolvin g host resolves the 
r equest as usual and sends it out over the (Inter- or In- 
ternetwork, but the( geTnu1tipteygrj 6 interposed be- 
tween the net work and the sg ryjce(s), to route the in- 
coming requests to one of the services. Note that in this 
case, there is still a single binding between the^^S_and 
the d emultiplexer 

A problem with this approach is that the demulti- 
plexe r acts as a limiting factor on throughput, and addi- 
tionally represents^asirigle source of failure for all of the 
services that it serves. A mechanism is needed whereby 
such a critical point and bottleneck can be avoided, 
while still providing access to the services for remote 
users. 

An alternative approach to tec^sjog congestion 
jsjhrough gyg^spcofihg, where the name resolver is 
fooled. into giving out a different name binding, by keep- 
ing the name resolver updated frequently with a new 
name resolution binding based on some criteria such as 
load distribution on target servers . An example of DNS 
spoofing is shown in Figure 2AJn which a requester 2 
issues a request using the name 'suapom", and, a DNS 
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IcokupJMooksjUjg;. The host (1, 2 or 3) to which the 
names js_bojjnd_wjlj de pend upon criteria employ ed at 
the destination dor nalru.asj jetermined by DNS spoo fing . 
s ervice_ 6. Such criteria may include lo ad on the h osts, 
th eir availability, et c. The DNS spoofing service^ polls 
th e hosts V-3 periodically or at demand, and binds one 
o f them at a time to the DNS lookup name resolver for 
the , name "sun.com". 

In a spoofing service, the criteria used to achieve 
the binding are not related to the context of the request- 
er; they rely only upon information at the destination. 
Thus, much information that could be important in mak- 
ing a binding is not utilized. In none of the known sys- 
tems is caller context used. 

It would accordingly be advantageous to have a 
system which takes into account tha context of the re- 
quester in the jjr oces^f namej'eso lution. 

Various respective aspects and features of the in- 
vention are defined in the appended claims. ~~ 
A ^context-depende nt name xesolutiQn_syjsiej7i is^l 
pr esented, which im ple ments p re dete rmined criteria for ( 
t§tatic or cjyjgaj 



i imple ments 
ading o_f_a 
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gral^obiects^f. the same tvge. Which ggbjecj)js select- 
ed for the bindin g is -deter mined, by a " name Resolve r" 
using context information t h at is explicitly specified by 
the requestorlin a name resoj ution lookup_call to the 
^ame-res6IVe?^TheMname-resolver a , which is imple- 
mented as aserverproQfam. stores a lookup table corn- 
uprising bindi ngs of a^nan^ ^ 

^sj>ya nc^ which de- 

fines the criteria for selecting aniin TStafnceiQf^e^ qbiectr 
For instance, the name may be an jntemejJJBL of th e 
f orm-www.s un. com and the resolved to object may be 
an IP address of the type 192.146.85.82. Thus the 
'name. resolver" will store the tuple: <www.sun.com> 
<IP_address_1> <IP_address_2>..., and will store pol- 
icies on which IP address to bind to www.sun.com when 
a lookup request specifying 'www.su n.com " is received 
by a. ^ ~ 

40 By enabling multiple, binding [support in the "name 
resolver", several advantages are realized. First, the 
svste m_enable s_ n ew resou rces to be added transpar- 
ently to the caller. When a new server is added to dis- 
tribute the jgggRe>ene or more hosts corresponding to 
45 the name^ sujig gn^fgr instance, the IP address for the 
new server is simply ad ded to the tuple in the nam e re- 
solv er, alon g with any de^ re ^ppNc^criteria^ g Jg_use 
only betwe en 9 ^mand 5 pjn . ^ 
Secondi^ThTTunidamental limit to scaling whichj s 
so inherent in today's single binding systems is removed, 
by enabling m ultiple destination^servers providing the 
sa me seryiceto be referenced by the same "napwh an- 
clle^by_the,caHer (for example "sun.com"), and the name 
t o be resolved by the name resoteerJo different phys ical 
55 co_mp_ut e_rs_s eryers, depending upon calle r ^context, 
ManyJnsjaoc£S_of jhe gamej;esotve^ be r unnin g 
o n diff erent physical computers, and manyjQstances of 
the services may ^ be runnin g , and the , r equester w ill ac- 
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c ess the narn ej-e solver closest to him; and the resol ved 
ggj ect that is clo ^estioJla&H ^ best 
serveJhe reauesti based upon some seJected.ojLpr ede- 
te rmined crite r ia ),wi]| Lb ie boy ndjoth i e J^^ggj^jiinrans- 
pare^lyJtoJIjejLejg advantage of the sys- 

tem of the invention is that it allows resources to be eas- 
ily replicated transparently to the user, eliminating any 
single point of failure in the network or at the service end 
point. If one valid destination fails, is not responding or 
is overloadegLthe name resolve r is already capable of 
binding a^namejlo multiple destinatio ns, and the una- 
vaila^le ^estina u^acafvea^is^bi ed irvOTe"name resolv- 
er's inter na^ tabjes, usi ng administrative means. 

The~^ntexj5that may be used as a basis for the 
binding is variab le; it may include information about the 
requester (e.g. requester IP address, domain name or 
inferred geographical region), about the destination 
(with similar alternatives), about the request itself (e.g. 
type or quality,of .service requested), or about indep,e nd- 
eiit.inforrnation (e.g. time of day or time zone of the point 
of origin of the request). 

The system may be implemented (eg as part of a 
computer apparatus) using hardware, software, or com- 
binations thereof. 

The invention will now be described by way of ex- 
ample with reference to the accompanying drawings, 
throughout which like parts are referred4o.by_like^refer- 
en^e^ 1 _andin_wh ich : 

Figures 1 -2A are diagrams of present network sys- 
tems used for destination addresses for requests. 

Figure 3 is a flow chart illustrating a method accord- 
ing to an embodiment of the present invention. 

Figures 4 and 5 are diagrams of network systems 
incorporating features of embodiments of the present in- 
vention. 

Figure 6 in an illustration of the operation o f an em- 
bo diment of the [n^ ntjon using geography-based res- 
olut ion criter ia. " 

Figure 7 is a diagram depicting zones in which do- 
main name service resotvers and service location re- 
solvers of the invention may be located. 

A method according to the invention is illustrated in 
Ftgure^and Fig u re s l4^5 shows a suitable systems im- 
plementable on the Internet or Worldwide Web, the In- 
ternet or an Intranet,, incorporating features of the name 
resolution system: 

Name resolutiorfc^an^clu^^nvkind of name res- 
ol ution lookup for binding onel^Die^tQi^ng t?^ This in- 
cludes binding the r1arrLe.0La .serv^ ut e r 
(ontsJPaddress) that piavidBsibatservice t .aaoLbinding 
th ^typjfoof service l o.the name of a service providin g 
thatlJg^^SBD/ice. I t also includes resolving a na me in 
on e domain to another name in the same domain , and 
to anotherjoa jTie in a different domai n. For the purposes 
of this invention, the t erms "ser vi ce' 1 and "h ggt!_can be 1 
con sidere d syjonymous, as can " service loc ation* and 
" host locatio n'. 
"The system includes Jhree J undamental features 
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that can be im^lemejited^ ajny^cojrnbinatk 
witb_ Qjie an other \rjiu7tipte bihdinc^of • destination, ad- 
d resses tonamfi Sjj ^kitecij gn^ xj^ame r esolution iricon- 
nection with sucr^ ^r^tipje^inding ) and name~resj3 lution 
^ijicv^b onsiderations, i.e. independenLcnteria upon 
whi ch such resolutiop is based 

Name Resolution : An Example 

An example of name resolution occurs, for instance, 
when a user wishes to view video, e.g.a movie, on his 
or her computer. An application running on the computer 
is used to make a procedure call to the name resolve r 
to determine whjgh server can serve a. movie., e.g. 

service_handle = name_servicejookup(/fnov1e s> }) 



w here the string "mov iej js passgpl to a fQ^g^wm ch 
then returns thejiama'offi thatmov- 



(Tejor it may rfituraalinkfidjist^^ 
je S, flojce.?, -from .whipM^-, u^qc.nmg^JjgJPjgg^^ to 
seject pn_ e) . 

The server may,, by way of example, return a^s ingle 
se rvice name, (e. g. "quicktime") in the variable called 
"se rvicejiandle". Next, the application must determine^" 
wh i cj^seTver h os EjfcarLpxoy ide th is se r yioejoJh isjc lient ; 
to.do this, it makes another name resolution call: 

- hostjiandle = name_hostname_lookup 
( service_handle ) 

and passes it the variable "servicejiandle" returned by 
the previous call. This call returns it th e name^o la.server 
which jsji sted as^offerinq this servi ce. 

The network location of this server must now be de- 
termined, so that the user's computer or workstation can 
connect to it to get the movie service, and-so it makes 
the call: 

hostj P_address = nqmejiostaddressjookup. 
(hostjiandle) 

and finally obtains an I P address of an appro priate ho st 
t hatcan provide the mo vie jseiyic^QJhBJJser, 




Further calls to this quicktime server may determine 
a list otmoyies.that are available. Alternatively, a design 
may be had in which the caller simply specifies the name 
of the movie he wants to.see, and the name lookup re.-l 
turns to the caller the IP address of a host that is cur- 
r ently able to serve the requestej ljaaQv4e4o4^e^atiei 
^ All of or some of the above steps may be combined 

in jri ore in tegrated calls to the name resp lver. 
* In the pr esent invention, in addition to the above , 
an additional <^paramete^ is passed tpTTjKc^ 
name Jiostaddress lookup 0 function above (or to all 
'the functions"abnva); t his parameter mav be calledj he 
( caller_cont5cT5this caller_context is used byjhe name 
r esolvertohelp it decide^whic^ ip address to use. Th us. 
>uld lo o k like: 

IP address = namejiostaddressjookup 
( fjost_hand) e, caller_cqntext). Caller_context is a cook- 
ie (oraTOctu re) that rpay include information sjjcjiasihe 
c aller's IP address, its point of origin, the quality of t he 
requested service, or any other cpntex tihat might be 



06/04/2003, EAST Version: 1.03.0002 



5 



EP 0 817 444 A2 



6 




relevant. These contexts must be well specified and 
t heir format (s) standardized, so that many different 
(£ $me resolvers) can interoperate^roperly. The particu- 
lar caller_context foTmlts and contents^seTected are n ot 
thamsah/es crucial, 

The present embodiment u ses requester conte xt- 
dependent intelligence to^determine which of sev eral 
destinatiogjb.03ts t ^rjoujd be utilized, -or in other word s, 
wh ir;h g f pa vocal |p addresses should be used to resolv e 
gquest. Th e, context-dependent.|ntell i- 
ented as hardwaje^software or a co m- 
binat io n of- bothya^iSwsithe^mame^feesotirtionng b e 
upon some^bnl^tinformaWn from the reques- 




torT5fio7qr upon the^name^being resolved in a context - 
fr ee manne r, but optionally' dependent upon criteria 
Rimh pfs^inad fraja ncjng^on the destination. 

As shown in Figure 4, a requesters 100-120, of 
which there may be an arbitrary number, each comprise 
computers or workstations on a local network, served 
by_ aserver 1 50 The requesters will typically be con ven- 
ti onal workstations, pers onal compute rs, or any net- 
wo rkable computing device , with local processo rs (1 30, 
etc.), memory (1 40, etc.), m ass stora ge (not shown) and 
network connections. The server 150 also includes a 
con ventional processor 16 0, memory 170, mass stor- 
age and necessary connections and control hardware 
and software. 

A name resolve r J80 f orms part of the server 15 0, 
or mav be a separateuni^ It may be implemented en- 
tirely in software, i.e. as program modules stored in 
mass storage and/or the memory 170, or it may be a 
st and-alone device , with its own logic or processor and 
memory, as desired. 

The server 1 50 is connected to a broader network 
170, such as the Internet, an Intranet or WAN (wide-area 
network), or the Worldwide Web, via a network connec- 
tion (e.g. a T-line) 260. On this network(t70ls o pJjoQal ly 
a nother name resolver 20 0. which may be implemented 
in the sam e fashion or differently f rom the name resolver 
1 80. Name resolve rs 1 80 and 200 may both be used, or 
either may be used by itself. (See discussion of Figure 
7, below.) 

Destination hosts 2J Q=230jT iav also be convention- 
al computers or workstations with processors (such as 
240), memory (such as 250), mass storage (not shown), 
network connections, etc., as needed to implement con- 
ventional network functions in addition to the features of 
the present invention. 

Referring to the flow chart of Figurej , when a re- 
quester (suc h asj 00-1 201 sends aC Qamb ~resolution re- 
quest-to a name, rasnlv aj iBp t instead of the single bind- 
ing of conventional syste ms, the name resolver 180 in- 
cludes m ultiple bindinaiables and/or functions (imple- 
mented by appropriate logic or program modules) to re- 
solve the request to an, appropriate IP aririrafls for a, Mes- 
ti natoLhos| (such as 210-230 in Figure 4). 

An example of such a multiple jbindin q would beJh e 
bindi ng _of multi pla^qeograpbicaljy_disparate-destipa- 



tions to a singl e domain n ame. If, for instance, a user in 
Germany wishes to access www.sun.com (the WWW 
server for Sun Microsystems, Inc.), he or she can simply 
use the U niform Resource Locat or (URL) B http://www. 

5 sunxom"). T hus^ the user sends the request from r e- 
quester^3T5)(see Figure 6), and tha nfflrpft rpsnh/ar ft?f) 
deteTminesJ hat-the requester is i n Germany. (See step 
20 in £iguxe_3). The selected-desiina uon~may eithe r be 
in the Uni ted States or elsewhere in Europe, since Sun 

10 Microsystems in this example hasjtwoJ|sun. com" lo ca- 
ti ons.. Since there is a valid European local destination 
330, the name resolver 320/ esorves the destination ad- 
dress to <smcgm>( E urope), as indicated at box 30 of 
Figure 3. Thlfre solved ^destination selected jpr 

15 the ^request packetfs ) (box 40 of Figure 3), and the re? 
questj s for warded to sun-.com (Europe) (box 50 of Fig- 
ure 3). 

Following are lists of c ontext<lependent resolut ion 
criteria applicable to the invent ion and usable at box 30 
20 o"tTi gure 3, where resolution may be based u ponjre^ 
quester_in formatio_n. destination information , r equest 
c onten ts, or ot her informa tion: — < 

A. Resolution Based Upon Requester Information 

25 

Exa mples of manners in whic h the resolution de- 
pendent-upojij^ujjsjer^^ 
include: 

30 1 . resolution based upon the d omain name of the 
sender; 

2. resolution based upon the inferred (looked-up) 
actual geographic region of the sender; 

3. resolution based upon other geography-related 
35 information of the sender: 

4. either directly ascertainable from the request 
(city/country info, e.g.); and/or 

5. indirectly ascertainable (area code, address, 
40 etc.); 

6. resolution based upon_gualit y_of_service de sired 
by the req uester; and 

7. resolution based upon requester' s time of d ay or 
45 tim e zon e. 

iL Resolution Based Upon Destination Information 

Examples of manners in which the resolution de- 
so pendent upon a specified or intended destination or re- 
ceiver information may be carried out include: 

1 . resolution based upon the load at the receiver; 

2. resolution based upon the inferred (looked-up) 
55 actual geographic region of the receiver; 

3. resolution based upon other geography-related 
information of the receiver: 
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4. either directly ascertainable from the request 
(city/country info, e.g.); and/or 

5. indirectly ascertainable (area code, address, 
etc.). 

s 

Criterion B.1 can be resolved either based upon in- 
formation as perceived at the sender end or based upon 
information as it exists at the receiver end, and resolved 
at the sender end. For example, the sender might fre- 
quently send requests to a particular server, service, ge- 10 
ographical region _or organization. In this case, it may be 
advantageous to regularly poll one or more often-used 
destinations to.determ ine.thei r J eve l(s) of activity^ Alter- 
natively, s uch poll in g cou Id a utomatical ly_be_ earned out 
for^any destinations for which the sender determines is 
that its number of requests exceeds a certain threshold, 
or for a top predetermined percentage of requests sent 
by the requester (e.g. all destinations for which the 
number of requests exceeds N1%, or the top N2 desti- 
nations to which the sender makes requests, where N1 20 
and N2 are appropriate predetermined numbers). Pol l- 
ing can be implementedjas program modules inte gral to 
the^aroe-.re ^olver( s), eithej ^entirelv in one o r in more 
than_ojTeJocation (e.g. partially in a local name resolve r 
and partially in the destination server). 25 

Alternatively or Jn^ addition, criteri on B.I m ay be 
based.uponjnformatkxvat the re ceive en d_ at the time 
of sej}g]na jhe request, and resolved at the j geeiv er. 

C J Resolution Based Upon Request Contents 30 



^tyj3£j2f^ejvice_req u ested ; 

2. specific information (or type of information) re- 
quested; 

3. any other implicit information inferred from the re- 35 
quest; and/or 

4. any other explicit information obtained from the 
request. 



D. Resolution Dependent Upon Other Factors *o 

1. random lyoejTeiated s election of de stination 
basegljipon<quaLifie^ 

2. oth er indep^h^eTntv^aev e loped information. 

45 

These resolution criteria can be used singly or in 
any desired combination with one another, as specified 
By the requester or the administrator of the destination 
](e.g. server owner or service provider). For instance, in 
the example of Figure 6 the resolution of the destination so 
address to sun.com (Europe) could be modified if the 
loa d of sun.co m (Europe) is largerjby-some-predeter- 
mined threshold amount than the load at sun.com (USA) 
- in which case the sun.com (USA) resolution could 
override the default sun.com (Europe) resolution for r e- ss 
qu esters in Europe, either at all times or only during 
peak European hoursTwhich correspond to off-peak 
hours in the United States. 



An ext ension of this, svslem4sJ n the res olution of 
se rvices provided at therejsaiveLjjetwork of a_ reques t. 
For instance, a given organization may have many da- 
tabase servers, and request for access to given infor- 
mation may in conventional systems be routed to the 
same server, because of the single binding nature of 
destination resolution. With multiple address resolution 
binding, multiple database-servers.(gjr other destination 
hosts) such as 210, 270, 280, etc. (see Figure 5) may 
be mad.e^ayailabJe.undeT^sjDpje^nam e, in which case 
a local service resolution server, such as server 300 in 
Figure 5, is provided. The server 300 includes tables, 
program modules or the like as desired to resolve a re- 
quest to- any one of several to many IP.addresses. The 
selection of a given server to receive a request can de- 
pend upon, for example, load at each of the servers. . 

In general, the resolution_sy€terns-or-subsystems 
wijLbejn one^oUhree^zones n (see Figure 7): the send- 
er|s_zone,1 (up to, e.g., the sender's firewall or Internet 
server); the n ame resolve r s ysterpls.zone 2 (which may 
be ajjseryeron the Internet, or_any _place outsid e zone 
1 whichis_not inthe receiver's syste m; and the receiver's 
zo ne__3. Service location name resolve rs ma v_be in any 
of zones _L3;Jypically, destination lookup^naiiie^resolv- 
ers, which may comprise multiple-bindipfl domain na me 
se rvices (DNS's ). will be in either zone 1 or zone 2. It 
wifTolTunderstood that zones, for the purpose of this 
application, are admini strative boundaries , and need 
not correlate to actual network boundaries. 

The present embodiment can int eract with existi ng 
systems in a number of ways. For instance, in secure 
systemswhere theTource address is stripped f rorrr the 
re quest by a firew all (and only, e.g., the domain name 
remains), then the entire source address would not be 
used to resolve_ the_ destination; the name resolver is 
provided with the program instructions or-drcuitry to im- 
plement this. Note also that the DNS name resolutio n" 
mayj 3e_adistinct opera tion fro m service locatio n, and 
th us thejjftf*tinfltion rgn , ha sel ected d ue jo a combina- 
t ion of considerations including source aqqressfre- 
gjjested destination address,, and jsquest content s, in- 
clu dinq the type of request made_or service reqi ^g gted * 
^_JQjemultjple binding feature of the invention allows 
^sigole name\ Internet address (e .g. URL address such 
asli!tp?/wwsun.corTt ^rthe Tn^to represent as ma ny 
a ctual ^iversV or services) as desired. Thi s has a dis- 
ti nct ad vamage of allowing modifications, upgrades or 
replic ations to~5e~made to the destination server(s) ffitfT^ ) 
<gu tjmodification of the destination address or service 
name as used by the requester Such modifications may 
include adding s ervers or services, o r establishing a mir- 
ror site at a location geographically near a large source 
of r equests, etc. 

There may be security and consistency implicat ions 
of multipleM ldiDfls, with concomitant solutions. If a des- * 
tin ation address can be multipj y_bflund, a name resol ver \i 
may be conj iqjJxedAoJ aind to.an incorrect address, eitherji 
brj6therwisii W hile this may also be a prob- J 
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lem with existing single binding, multiple binding m ay 
com plicate detection of the prob lem. Thus, the system 
of the invention may be combined with programs and 
tablejXQLV-eiifi cation that a given binding is valid . Very 
se cure systems may wish to limit their multiple.b inding 
to ao redetermined. fixed number of resolution possib il- 
ities, or even maintain t he current system of single bin d- 
ing a s far as Interne t or Web transmission is concerned, 
ar^mplement multip^ binding only behind a firewall. 
Alternatively or^in addjjion, encryption and digital signa- 
tures may be use dlo ens ure yalidity of jajndings. and of 
mo difications or additions t o the bindings. 

Variations may be had by designating a given name 
r esolution as a default re s olutio n, and utilizing alterna- 
tive r esolution s only upon the request meeting prede- 
termined criteria (such as load imbalance, geographical 
distance, specific sources of the request, etc.). 

Additional bindings (i.e. additional addresses to 
which a request may resolve) may^be-adde d_withoutth e 
r equester being aware of it, and indeed substitutions 
may b e made at any time, again transparently to the re- 
quester. 



R Service Selection Based Upon Caller Cfbntext. 

The system of the invention may be applied more 
generall y to the us eo f caljer context lor name . r . esolutjo n . 
Conte xt ato u tjhe^requesting us er (e.g. in a variable 
called^c ajSr_context /) can be p assed ta _appropriate 
f unctions, suc h as: 

seryjce_handle = name_service_lookup( "movie", 
cal]ej^_context) 

host_handle = name_hostname_lookup 
(service_handle, caller_context) 
Here, the function service_handle executes a service 
name lookup bajejj ; ^njhejnput ^" ^yi^ asjwell as 
the inf ormation i njhe variable caller context, outputting 
th e value serviceJiandle^Given this out'purasjnput 
al ong with (ag ain) calle r context, the fu nction 
h ost jiandle then returns an appropriate host name. 

An example of a possi ble such situation could result 
whe n a user desires an<en5^tioj}^ervic e?and several 
ejncryptionjDolicies are ^available. The servicejiandle 
function can be configured t o return different encryptio n 
algorit hm services based upon the specified destination 
(which is specified in caller_context), or there may be 
an effective override in the caller_context by which the 
user can select a higher level of security 

I n general, as noled_ J aboye._theJny_ention may be 
i mplemejited^at^^ destina- 
tic^^terrL^dndeed at Points^n fretwaen (e.g. at proxy 
servers). Note that single points of failure and bottle- 
necks are removed using the present system, and a truly 
distributed, multiply binding name resolution system is 
achieved. 

Particular and preferred aspects of the invention are 
set out in the accompanying independent and depend- 
ent claims. Features of the dependent claims may be 
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combined with those of the independent claims as ap- 
propriate and in combinations other than those explicitly 
set out in the claims. 



Claims 



A system for name resolution of at least one request 
directed to a destination name of a receiver and is- 
sued from a requester system, including: 

a name resolver connected to the requester 
service and including 

predetermined information correlating a plural- 
ity of destination addresses with said destina- 
tion name; 

"~a criteria selection subsystem configured t o 
provide a selection of at least ope said desti na- 



[onej 

tion address based upon at least one oredeter - 
- npined criterion; and 
a destination address binder configured to bind 
said destination name with said selected desti- 
nation address. 

The system of claim 1 , wherein said at least one 
predetermined criterion includes a criterion based 
upon information explicitly contained within said re- 
quest. 

The system of claim 2, wherein said information in- 
cludes an address of said requester. 

The system of claim 2, wherein said information is 
based upon at least a portion of contents of said 
request. 

The system of claim 4, wherein said portion of said 
contents includes at least one of: 

a type of service requested by said request; and 
a quality of service requested by said request. 

The system of claim 1 , wherein said at least one 
predetermined criterion includes a criterion based 
upon information not explicitly contained within said 
request. 

The system of claim 6, wherein said information 
pertains to a geographical region of said requester. 

The system of claim 6, wherein said information 
pertains to a geographical region of said receiver. 

The system of claim 6, wherein said information in- 
cludes load information relating to said receiver. 



10. The system of claim 6, wherein said information in- 
cludes at least one of time and date information. 
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11 . The system of claim 1 , wherein said binding is to a 
port at said destination address. 

12. The system of claim 1, wherein said binding is 
based at least in part upon a random selection of 
one said destination address. 

1 3. A method for context-dependent binding of a desti- 
n ation name to_a destination address in a name re - 
solver having a predetermined set of binding cri teria 
and predetermined correlations of destination 
names with destination addresses, wherein at least 
one said correlation is a multiple correlation corre- 
lating a plurality of said destination addresses with 
a single destination name, including the steps of: 

(1) receiving said request at said name resolv- 
er; and 

(2) b ased upon said mul tiple correl ation , re- 
trieving at least one said destination aadress 
from said pl urality of destination address es. 

14. The method of claim 1 3, further including after step 

2, the step of: 

(3) binding said retrieved destination address 
to said destination name. 

15. The method of claim 14, further including after step 

3, the step of: 

(4) transmitting said request with said desti- 
nation address. 

16. The method of claim 13, wherein said multiple cor- 
relation is based upon information explicitly con- 
tained within said request. 

17. The system of claim 13, wherein said multiple cor- 
relation is based upon at least a portion of contents 
of said request. 

18. The system of claim 13, wherein said multiple cor- 
relation is based upon at least one of: 

an address of said requester; and 

a type of service requested by said request; and 

a quality of service requested by said request. 

19. The system of claim 1 , wherein said multiple corre- 
lation is based upon information not explicitly con- 
tained within said request. 

20. The system of claim 1 9, wherein said multiple cor- 
relation is based upon at least one of: 

a geographical region of said receiver; 
load information relating to said receiver; 
time information; 
date information; and 



a random factor generated by said name re- 
solver. 

21 . A system for name resolution of at least one request 
5 directed to a destination name of a receiver and is- 
sued from a requester system, the request informa- 
tion relating to caller context, the system including: 
a name resolver connected to the requester 
service and including 

10 

predetermined information correlating a plural- 
ity of service names with said caller context; 
a service selection subsystem configured to 
provide a selection of at least one said service 
is name based upon said caller context; and 

a host name selection subsystem configured to 
return a host name based corresponding to 
said selected service name. 

20 22. The system of claim 1 , wherein said at least one 
predetermined criterion includes: 

a first criterion based upon information explic- 
itly contained within said request; and 
25 a second criterion based upon information not 

explicitly contained within said request. 

23. The system of claim 22, wherein said second crite- 
rion corresponds to a predetermined policy used by 

30 said name resolver. 

24. The system of claim 23, wherein said first criterion 
corresponds to information relating specifically to 
said requester system. 
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